Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/orad/orad-minutes-93mar.txt

Text File | 1993-05-17 | 8.2 KB | 265 lines

CURRENT_MEETING_REPORT_


Reported by Bernhard Stockman/EBONE

Minutes for the Operational Area Directorate (ORAD)

Agenda


   o Operations Area Mandates

      -  Operational standards
      -  Operational Requirements
      -  Operation Coordination
      -  Review of standards


   o Coordination Issues

      -  Routing - Policy Language
      -  Routing Policy Registration


   o Coordination of Tunnels

      -  MBONE
      -  TBONE
      -  *BONE


   o Operational Impact if IPNG

   o Class C Allocation Forecasts


Side notes

Do we need a single WG to handle issues regarding ``virtual Internets''
sitting on top of today's IP internet.

How will the large blocks of Class Addresses allocated affect current
routing platforms

Operational Area Mandates

Coordinations of network service providers; is it the job of the IETF?
``I can see no less biased venue.''  - Gene Hastings

Historically the IETF has been a venue for providers to discuss the
leading edge technology they have been deploying and to give developers
feedback.

                                   1





It seems as if providers are swamped by the rapid growth of the
Internet.  This forum allows providers to work on problems ``at the top
of the list.''  As the Internet continues to grow, more
``fire-fighting'' resources may become available.  At that time some
other forum for NSP coordination may be appropriate...  (i.e., Someone
else may be willing to host such a forum.)

Is it good to meet at the IETF? A great deal of technology of transfer
takes place.  If a separate operational venue is developed, it should
collocate with the IETF. Another separate set of meetings would be
poorly attended, as network operators have too many meetings to attend
as it is.

As for reading for RFCs.  If the Operational Directorate read RFCs,
would that alleviate some of the problems we have now?  Many RFCs have
fallen through the cracks towards complete implementation without
operational issues being addressed (e.g., RFC1400).  Informational RFCs
need to be addressed as they don't follow a standards track.

What about ``executive cooperation?''  A lot of informal agreements are
made at the IETF meetings, but they can't be backed without network
higher-ups agreeing to it.  Thus the purpose of the meeting should be to
coordinate operation of individual networks, not to change each
network's own policy.

A certain amount of consensus is built up in the operational area.  The
operational area seems to have fuzzy objectives and less concrete
standards.

NSP coordination actually also takes place within other organizations,
e.g., FARNET.

We'll continue to do things they way we are.  If another forum develops,
it would be wise to collocate it with the IETF meetings.

One thing that ORAD needs to address is a mechanism to apply an ``ORAD
seal of approval.''  There needs to be a mechanism to alert ORAD to
[informational] RFCs which have significant operational impact.

John Curran agreed to make sure that the job of reading at least a
fraction of new RFCs for operational impact is handled.  Bill Manning
agreed to do some reviewing, but cannot do the whole job himself.

There is a need for a working group to deal with a policy routing
description language.  Many of the routing efforts (BRG, SDRIP, etc.,)
are defining a need for a common routing policy language.  ORAD needs to
form a liaison with the protocol developers to help define such a
language.

It is possible that the Internet Working Group should be revived to deal
with topology configuration.  Such a group could form the liaison with
the routing protocol developers to give input as to how develop future
protocols.


                                   2





Dan Long's proposed structure (areas to be addressed):


   o BGP Deployment - protocol/CIDR
   o IWG - NSP Routing Coordination
   o NSR - Growth
   o Tunnel OPS - Coordinate the deployment of things like MBONE, etc.
   o OPSTATS
   o NOOP
   o ORAD
   o UCP (???)  - Gas running out - Possible to roll into NJM
   o Benchmarking - Bradner
   o NJM (new) - coordination of NSP, trading troubleshooting
     techniques, operational experience


Three different types of working groups:


  1. Exchanging Information
  2. Coordinated/establishing operational procedures
  3. Engineering standards (e.g., benchmarking.)
  4. IWG/Tunnel Ops - Operational planning.
  5. NJM/UCP/NOOP - Diagnostic procedures


Tunnel Coordination

No critical mass to form an MBONE engineering group.  However, a number
of different tunnel types may need to be organized to keep the
collection of ``BONES'' melts down the Internet.

MBONE seems to be causing operational problems.  It is quite possible
that this is the first of many other tunnel types which will appear
again.

Matt Mathis reported the happenings at the MBONE BOF.


   o General Issues
   o Procedures
   o Topology, Metric, and threshold engineering
   o Bandwidth Budget and policy
   o Infrastructure oriented tools (wish list)
   o Transport and application diagnostic tools (wish list)


MBONE is only an example of very steep growth rates.  It is hard to tell
end users to not to use their connection whether it be MBONE, AFS,
Internet Talk Radio, etc.

At this point there is no need to address these issues with a working
group, however it would probably be wise to hold some sort of meeting

                                   3





before or at the next IETF. Discussion will be held on the ORAD list to
organize such a meeting.

Call C Allocation Forecasts

Will CIDR save us in time to keep our routers from falling apart from
too many routes?  he number of Class C nets being allocated our quite
high.  The NSFNET routing table has grown at a rate of 6.5% per month.
We'll probably see 10,000 routes by July.  Is deploying CIDR going to
save us?

Which networks will hit the limit before CIDR is deployed?  ANS feels
their situation is undercontrol, but other service providers may feel
the crunch.

Controlled deaggregation may need to be dealt with for those providers
who can't speak BGP4 but can't default.  Ground rules need to be laid to
define this policy.  A mechanism also needs to be defined for
negotiating the amount of aggregation which takes place between two
networks.

We're not sure when things will fall apart, so we may just have to deal
with the problem when it occurs.  All we can do is keep trying to get
CIDR deployed in time and try to beat the clock.

ANS is also performing tests with cisco and IBM routers to see how many
routes can be flapped in and out before they suffer server performance
degradation.

Attendees

Tony Bates               [e-mail]
Serpil Bayraktar         [e-mail]
Erik-Jan Bos             [e-mail]
Rebecca Bostwick         [e-mail]
Douglas Carson           [e-mail]
Henry Clark              [e-mail]
David Conrad             [e-mail]
John Curran              [e-mail]
Tom Easterday            [e-mail]
Dale Finkelson           [e-mail]
Francois Fluckiger       [e-mail]
Eugene Hastings          [e-mail]
Alisa Hata               [e-mail]
Ittai Hershman           [e-mail]
Steven Hubert            [e-mail]
Dale Johnson             [e-mail]
Merike Kaeo              [e-mail]
Daniel Karrenberg        [e-mail]
Charley Kline            [e-mail]
Daniel Long              [e-mail]
Kim Long                 [e-mail]


                                   4





Peter Lothberg           [e-mail]
Glenn Mackintosh         [e-mail]
Bill Manning             [e-mail]
Matt Mathis              [e-mail]
Dennis Morris            [e-mail]
Peder Norgaard           [e-mail]
David O'Leary            [e-mail]
Andrew Partan            [e-mail]
Brad Passwaters          [e-mail]
Kim Smith                [e-mail]
Bernhard Stockman        [e-mail]
Marten Terpstra          [e-mail]
Kaj Tesink               [e-mail]
Claudio Topolcic         [e-mail]
Curtis Villamizar        [e-mail]
Ruediger Volk            [e-mail]
Linda Winkler            [e-mail]
Cathy Wittbrodt          [e-mail]
Paul Zawada              [e-mail]



                                   5